1. Field of the Invention
The present invention relates to reusable software component types and, in particular, to the promotion of features from instances of such software component types to others of such software component types.
2. Description of the Related Art
Software systems are built from pieces of software that interact with each other to accomplish a common goal. These pieces of software have different names, which may depend on the programming language in which the pieces are written and the abstraction level that is being considered. Examples of pieces of software include “procedures”, “objects”, “blocks”, “processes”.
To ease the maintainability of code and to improve the efficiency of creating code, in the process of building software programs, programmers build software component types that are reused through a process called “instantiation”. Through this process of instantiation, an instance (a software component) of a software component type is created . An instance of a given software component type has all the “features” of the given software component type and these features may be customized for that instance. For example, if the given software component type has a feature “color”, then, in the instance, the feature “color” may be customized to a particular color, e.g., “red”. In this document, we understand a feature to have a name and a value.
These pieces of software may be composed of instances of reusable software component types. A software component type, or a template, may be called a “Part”. Specifically, example parts are a C++ class, a Java™ Class, a Flow in Flow Composition Builder (“FCB”, marketed by IBM of Armonk, N.Y.) or a meta-level (say, M2) in Meta Object Facility. Java is a trademark of Sun Microsystems. As will be apparent to a person skilled in the art, Meta Object Facility (MOF) is a standard from the Object Management Group (OMG) that builds on and extends the Extensible Markup Language (XML) and the Unified Modeling Language (UML). An instance of a reusable software component type (Part) may be called a “Sub-Part”. Example Sub-Parts are a C++ object, a Java™ object, a FlowComponent in FCM or a meta-level (say, M1, where M1an instance of M2) in MOF.
A Part may be built by aggregating instances of other Parts. Instances are considered as being constituent Sub-Parts of the Part and a Part is considered as being an aggregation of Sub-Parts. Parts which are being composed of an aggregation of a set of instances of other, predetermined Parts are called “Parts under composition”. “Visual hierarchical composition though aggregation” is a process, typically used in tools for writing software, used to compose Parts from Sub-Parts. The process can be described with the visualization of two levels, a “Level 2” containing Parts and a “Level 1” containing Sub-Parts. Each Sub-Part on “Level 1” is an instance of a Part from “Level 2”, that is, the behavior and structure of each Sub-Part is defined by the Part from which the Sub-Part is instantiated. Every Part can have many instances in “Level 1”. New Parts may be composed through the aggregation of instances (Sub-Parts) of predetermined Parts.
Classically, features of Parts are customized in the creation of Sub-Parts. Consider a predetermined Part constructed with a “color” feature. When a user creates an instance (Sub-Part) of the predetermined Part, the user sets the color feature to a value, e.g., red. A Part under composition may subsequently include the red instance of the predetermined Part. When the user creates an instance of the Part under composition, the user does not have the opportunity to set the value of the color feature to anything but red nor does the user have the opportunity to remove the “color” feature from that instance.
Where two instances of the original Part under composition are required, each with a different color, the user would have had to compose two new Parts instead of one. The first of these new Parts under composition would be aggregated from the same set of instances of the other, predetermined Parts. The second of these new Parts under composition would be aggregated from most of the instances of the other, predetermined Parts with the exception that a differently colored instance of the aforementioned predetermined Part is used. Subsequently, a Sub-Part would be instantiated from each of the two new Parts.
Clearly, there is a need for a mechanism to allow customization of features of Parts (reusable software component types) upon instantiation that does not require the composition of further Parts.